[Salesforce]社内用の見積承認プロセスを構築してみた

Hola〜皆さんこんにちは！Salesforceシステム管理者の清水です。

今日はSalesforceの標準機能で用意されている承認プロセスを利用して、社内用に見積の承認プロセスを構築した内容をご紹介したいと思います。

承認プロセス・動的アクション・入力規則を駆使すればNon Codeでかなりのことが出来たのですが、Salesforce特有の設定もあり理解するまで何度もサポートとやりとりした経緯があります。

皆さんお忙しいと思うので、同じように困っている管理者・開発者の役に立てば幸いです。なお詳細な承認プロセスの設定などについては公式にもあるので割愛し、主に私が設定した中で、つまづいたポイントについて触れていきたいと思います。

承認プロセスの設定の流れ

承認プロセスの要件をまとめる

まずは承認プロセスを利用するにあたって、社内の要件を取りまとめました。その結果以下のパターンに落ち着きました。

A事業本部

• 承認不要な商品を営業が選んで見積書を発行したいときには、承認プロセスは走るが、マネージャーが承認ボタンを押さずに自動承認にしたい。
• それ以外の商品も一緒に選んで見積書を発行するときには、マネージャーが内容を確認してから承認したい。
• 金額が100万円を超えると上位承認者へ申請が上がるようにしたい。

B事業本部

• Salesforceアカウントを持っていないスタッフが承認者になる場合もある。営業が見積書を発行した後に、社内の別のツールを利用して実際に承認をとるので、Salesforce上で承認プロセスは走るが、実際には全て自動承認にしたい。

C事業本部

• 全ての商品において、マネージャーが内容を確認してから承認したい。

マネージャー自身が、見積書を発行したい

• ユーザーアカウントに、マネージャーの設定がないスタッフが自分自身で見積書を発行したい。承認者は不要。

Cacooを使って、要件を図に起こす

文章だけでは、利用者全員がなんとなくしか仕組みを理解できないので、部署ごとにこのようなフロー図を作成しました。社内用のマニュアルを用意しておいてこちらを貼っておくだけで、ユーザーの理解度が変わるかと思います。

 

承認プロセスを作成

内容が決まったら、実際に承認プロセスを作成していきます。

設定は色々できると思いますが、弊社の場合各部署ごとに要件が違っていて後々管理者が一番トラブル対応しやすい方法を考えたときに、部署ごとに複数用意した方が結果シンプルかなと思ったのでそのようにしました。１つの承認プロセスで、開始条件を複数入れるやり方ももちろんあるかとは思います。

そして各部署ごとに、作成した承認プロセスの開始条件に、プロファイルの設定を入れていきました。

以前は、全部署の営業をシンプルに１つの「営業」プロファイルにしていたのですが、ページレイアウトや項目を部署ごとに分けたり、アプリケーションの割り当てを考えると、どうしても弊害が出てきたので、今年に入り部署ごとに分けました。

結果、上記のような承認プロセスの条件指定が簡単にできるようになり助かりました。

つまづいた点

商談商品の内容によって承認を自動化したいとき

形式化されているような商品で、マネージャーが毎回チェックをしなくても見積書を発行したいと言ったようなケースもあると思います。そうなったときに承認プロセスには開始条件を指定をして、この商品が含まれている見積は自動承認といったようにできますが、その条件フラグをどうやって作るのかといった時に苦戦したので、その仕組みをご紹介します。

開始条件の指定

承認プロセスの開始条件に指定するときに、直接商品オブジェクトの項目指定ができないので、商談や見積のどちらかに判定フラグなどを作る必要があります。

判定フラグを以下のように設定

• 承認不要にしたい商品をこのように１つ作成し、価格表エントリIDを取得
• 弊社の以下のケースのように１つの価格表の場合は、1IDで済みますが、複数価格表が存在する場合は複数のIDをメモしておく
• 商品IDでいいのでは？と思うが、後々の設定で必要になる[商談商品]レコードが直接リレーションを持っているのは[価格表エントリ]であり、 [価格表]および[商品]への直接のリレーションは持たない構造。 そのため[価格表エントリID]を使用する必要があり、 [価格表]や[商品]のIDを活用することは出来ない

商談商品オブジェクトに、価格表エントリIDを表示する数式項目を作成

商談オブジェクトに先ほど作った商談商品の項目から、承認不要・必要の商品を集計する項目を作成（最初に調べておいた価格表エントリIDを入れます）

商談オブジェクトに、[承認プロセス不要]の数式項目を作成（数式は要件によって適宜変更してください）

このように「承認不要商品」が１つ含まれていればチェックを入れるといったようになりました。

あとは、このチェックボックスがONになっているときに承認プロセスを動かすといったように開始条件を指定します。

承認ステップで、自動承認になるような条件を指定します。

割り当て先の選択で、申請者自身に自動で割り当てするようにします。ここが最初マネージャを割り当て先にしてマネージャーが手動で承認ボタンを押さなくても、特定の商品のときだけ自動承認できるのかテストしたのですが、どうやらサポートから回答をもらって現状できないようです。なので自分自身に割り当て先を設定しました。

自動で承認されるよう設定した場合には「承認者＝申請者」の動作となってしまい、自動承認にて承認者を指定する機能のご用意は、Salesforceの標準機能として現在のところ提供がない状況でございます。

レコードのロック・解除の動作について

承認プロセスでは最終承認時・却下時・取り消しの際のアクションを取り決めできますが、この時にレコードのロック・解除の動作でつまづいた点を紹介します。

当初、弊社では見積申請中・承認後には全ての見積レコード・商談商品レコードでユーザーが編集できないような運用にしたかったのですが、ロックの設定をすると、編集が必要な項目まで編集出来なくなってしまったので、最終承認時のアクションに「レコードのロック」設定はできないと感じました。

そのため以下のように、「レコードのロックを解除」する設定にしたのですが、それだとせっかく承認プロセスを経てマネージャーのチェックが入った見積や商談商品レコードをユーザーが好きなように編集できてしまいます。

なので入力規則を利用して、見積承認後でも見積レコードは編集不可・商談商品も特定の項目を除いて編集できないように設定しました。

ちなみに、入力規則でシステム管理者の他に特定のメンバー（ある権限セットを割り当ててるメンバー）だけ、常に編集できるようにして置きたかったのですが、権限セットでは指定ができず、UserIDで入れる必要があります。

それだと人数が増えたときに大変なので、ユーザーオブジェクトにチェックボックスを作成し、そのチェックがついてるメンバーといった形で入力規則に指定しました。

代理承認者の動作について

承認者であるマネージャーが不在の場合、代理承認者の方でも同じように承認ができる便利な機能が存在していますが、いくつか混乱した点があったので記載します。

１、代理承認者を設定する場所は、マネージャーのアカウント上にする必要があること

私は最初、申請者にあたるメンバーのアカウント上に代理承認者の設定を行っていたのですが、何度検証しても代理承認者がその承認申請へアクセスができませんでした。そのためサポートへ確認してみたら、メンバーではなくマネージャーのアカウントに代理承認者を設定する必要があると言われました。ここは間違いやすいポイントだと思うので、注意が必要です。

２、代理承認申請一覧について

「未承認申請」一覧に承認者と同じように、承認一覧が表示されない点があります。

これ自体は調べるとすぐに出てきたので理解できたのですが、代わりにClassic画面からレポートへアクセスし、「代理承認申請一覧」をクリックし、レポートを作成しないと代理承認者は一覧で確認ができないという点です。Lightningでは対応していないため、レポート作成ができないようです。

３、代理承認者には「承認」・「却下」しか選べず「再割り当て」はできない

あくまで代理という位置づけだからなのでしょうか？承認者と全て同じではないようです。

 

承認プロセス変更後に起きた課題

Sandboxでテスト時に予想していなかったのですが、今回承認プロセスを新しく作成したのと同時に今まで利用していた古い承認プロセスは無効化しました。

その結果、古い承認プロセスを利用して作られた見積や商談商品のレコードを、ユーザーが編集しようとした際にエラーが発生しました。

1. 現在の承認プロセス：最終承認後レコードのロック解除
2. 昔の承認プロセス　：最終承認後レコードのロックをする（ただしプロファイルで「全て変更」権限与えてたので、ユーザー側からは見積の編集が可能だった）

今回の承認プロセスの変更で、同時にこのプロファイルの権限設定も変更して「全て変更」権限は取ってしまったため、ユーザーからすると古い見積や商談商品の編集をしようとしても「ロックされています」と表示が出てしまいます。

サポートにこの問題の対処法を確認したのですが、システム管理者の方でClassic画面から１レコードずつロック解除していくしか方法がないということでした。（Lightningではレコードのロック解除が対応していないとのこと）

なおデータローダー を利用してAPI経由で一括処理をすることもできず、唯一ロック解除できる方法がApex コードによって承認プロセスによるロックまたはロック解除を一括で実行する方法だそうです。

参考：Apex コードによる承認プロセスのロックおよびロック解除の設定

これは、弊社のように開発者がいればそちらの方法を試すことができますが、管理者のみで利用している企業様だと管理者が手作業でロックするまたは解除する作業しか選択肢がないので、厳しいなと感じました。

終わりに

今回この作業に費やした時間はトータルで一ヶ月ほどでした。これが弊社よりさらに大規模な組織での変更になってくると、Projectを立ち上げて半年、一年かかるケースもあるのではないでしょうか？

弊社の場合、本番リリース前に部署ごとにSandbox環境でマネージャーとメンバーに実際に触ってもらって、レクチャーを何度か繰り返しました。承認プロセスはレクチャーを主要メンバーへ必ず行い、利用方法のマニュアルを利用者全員に必ず読んでもらうようにしないとリリース後に問い合わせが殺到してしまう内容の１つかと思います。

設定方法については、公式にも細かく載っているのである程度わかると思いますが、実際に管理者や開発者の方がやってみた所感を書いたブログをあまり発見することができなかったので、どなたかのお役に立てれば幸いです。